home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-mimemhs-harpoon-01.txt < prev    next >
Text File  |  1993-03-03  |  8KB  |  344 lines
  1. draft                          HARPOON                          Jan 93
  2.  
  3.  
  4.                                  HARPOON
  5.       Rules for downgrading messages from X.400/88 to X.400/84 when
  6.               MIME content-types are present in the messages
  7.  
  8.                        Tue Feb 23 10:06:57 MET 1993
  9.  
  10.  
  11.                          Harald Tveit Alvestrand
  12.                                SINTEF DELAB
  13.                    Harald.T.Alvestrand@delab.sintef.no
  14.  
  15.  
  16.                               Jim Romaguera
  17.                               NetConsult AG
  18.                       Romaguera@cosine-mhs.switch.ch
  19.  
  20.  
  21.                                Kevin Jordan
  22.                         Control Data Systems, Inc.
  23.                          kej@mercury.udev.cdc.com
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.     Status of this Memo
  31.  
  32.          This document is an Internet Draft.  Internet Drafts are
  33.          working documents of the Internet Engineering Task Force
  34.          (IETF), its Areas, and its Working Groups. Note that other
  35.          groups may also distribute working documents as Internet
  36.          Drafts.
  37.  
  38.          Internet Drafts are draft documents valid for a maximum of
  39.          six months. Internet Drafts may be updated, replaced, or
  40.          obsoleted by other documents at any time.  It is not
  41.          appropriate to use Internet Drafts as reference material or
  42.          to cite them other than as a "working draft" or "work in
  43.          progress."
  44.  
  45.          Please check the I-D abstract listing contained in each
  46.          Internet Draft directory to learn the current status of this
  47.          or any other Internet Draft.
  48.  
  49.          If consensus is reached in the IETF MIME-MHS Interworking
  50.          Working Group, it will be submitted to the IESG asking that
  51.  
  52.  
  53.  
  54.  
  55.  
  56. Alvestrand et al         Expires Aug 23 1993                  [Page 1]
  57.  
  58. draft                          HARPOON                          Jan 93
  59.  
  60.  
  61.          it be recommended to the IAB as a Proposed Standard protocol
  62.          specification.
  63.  
  64.          HARPOON stands for Holistic Approach to Reliable Provision of
  65.          Open Networking, and is used solely to catch the eye of
  66.          readers.
  67.  
  68.          Please send comments to the MIME-MHS mailing list
  69.          <mime-mhs@surfnet.nl>
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Alvestrand et al         Expires Aug 23 1993                  [Page 2]
  114.  
  115. draft                          HARPOON                          Jan 93
  116.  
  117.  
  118.     1.  Introduction
  119.  
  120.     Interworking between X.400(88) and MIME is achieved by [MAPPING],
  121.     which modifies RFC-1327 [RFC 1327], which specifies the
  122.     interworking between X.400(88) and RFC-822 based mail.
  123.  
  124.     Interworking between X.400(88) and X.400 (84) is achieved by RFC-
  125.     1328 [RFC 1328]. That document does not describe what to do in the
  126.     case where body parts arrive at the gateway that cannot be
  127.     adequately represented in the X.400(84) system.
  128.  
  129.     This document describes how RFC-1328 must be modified in order to
  130.     provide adequate support for the scenarios:
  131.  
  132.     SMTP(MIME) -> X.400(84)
  133.  
  134.     X.400(84) -> SMTP(MIME)
  135.  
  136.  
  137.     2.  Basic approach
  138.  
  139.     The approach is to imagine that the connection X.400(84) <->
  140.     SMTP(MIME) never happens. This, of course, is an illusion, but can
  141.     be a very useful illusion.
  142.  
  143.     All mail will therefore go on one of the paths
  144.  
  145.     X.400(84) -> X.400(88) -> SMTP(MIME)
  146.  
  147.     SMTP(MIME) -> X.400(88) -> X.400(84)
  148.  
  149.     when it goes between a MIME user and an X.400(84) user.
  150.  
  151.     The approach at the interface between X.400(88) and X.400(84) is:
  152.  
  153.  
  154.     o    Convert what you can
  155.  
  156.     o    Encapsulate what you have to
  157.  
  158.     o    Never drop a message
  159.  
  160.     Of course, for X.400/88 body parts that are already defined in
  161.     X.400/84, no downgrading should be done. In particular, multi-body
  162.     messages should remain multi-body messages.
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Alvestrand et al         Expires Aug 23 1993                  [Page 3]
  171.  
  172. draft                          HARPOON                          Jan 93
  173.  
  174.  
  175.     3.  IA5 fallback format
  176.  
  177.     For any body part that cannot be used directly in X.400(84), the
  178.     following IA5Text body part is made:
  179.  
  180.  
  181.     -    Content = IA5String
  182.  
  183.     -    First bytes of content: (the description is in USASCII, with
  184.          C escape sequences used to represent control characters):
  185.  
  186.          MIME-version: <version>\r\n
  187.          Content-type: <the proper MIME content type>\r\n
  188.          Content-transfer-encoding: <quoted-printable or base64>\r\n
  189.          <Possibly other Content headings here, terminated by\r\n>
  190.          \r\n
  191.          <Here follows the bytes of the content, as per [MAPPING], encoded
  192.          in the proper encoding>
  193.  
  194.  
  195.     All implementations MUST place the MIME-version: header first in
  196.     the body part. Headers that are placed by [RFC-1327] and [MAPPING]
  197.     into other parts of the message MUST NOT be placed in the MIME
  198.     body part.
  199.  
  200.     Since all X.400(88) body parts can be represented in MIME by using
  201.     the x400-bp MIME content-type, this conversion will never fail.
  202.  
  203.     In the reverse direction, any IA5 body part that starts with the
  204.     token "MIME-Version:" will be subjected to conversion according to
  205.     [MAPPING] before including the body part into an X.400(88)
  206.     message.
  207.  
  208.  
  209.     4.  Implications
  210.  
  211.     The implications are several:
  212.  
  213.  
  214.     -    People with X.400(84) readers who have the ability to save
  215.          messages to file will now be able to save MIME multimedia
  216.          messages
  217.  
  218.     -    People who can use features like the "Mailcaps" file to
  219.          identify what to do about a bodypart can now grab MetaMail or
  220.          MHN and achieve at least some multimedia functionality
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227. Alvestrand et al         Expires Aug 23 1993                  [Page 4]
  228.  
  229. draft                          HARPOON                          Jan 93
  230.  
  231.  
  232.     5.  Security considerations
  233.  
  234.     The security considerations in [MIME] and [MAPPING] (beware of
  235.     trojans that can hit you if your UA automagically starts programs
  236.     for you) are now relevant also for X.400(84) systems.
  237.  
  238.  
  239.     6.  Authors' address
  240.  
  241.     Harald Tveit Alvestrand
  242.     SINTEF DELAB
  243.     N-7034 Trondheim
  244.     NORWAY
  245.     Harald.T.Alvestrand@delab.sintef.no
  246.  
  247.     Kevin E. Jordan, ARH215
  248.     Control Data Systems, Inc.
  249.     4201 Lexington Avenue N
  250.     Arden Hills, MN  55126
  251.     USA
  252.     Kevin.E.Jordan@mercury.oss.arh.cpg.cdc.com
  253.  
  254.     James A. Romaguera
  255.     NetConsult AG
  256.     Mettlendwaldweg 20a
  257.     3037 Herrenschwanden
  258.     Switzerland
  259.     Romaguera@cosine-mhs.switch.ch
  260.  
  261.  
  262.     7.  References
  263.  
  264.     [MIME]
  265.          N. Borenstein, N. Freed, MIME: Mechanisms for Specifying and
  266.          Describing the Format of Internet Message Bodies.  RFC 1341
  267.  
  268.     [RFC-1327]
  269.          S.E. Hardcastle-Kille, Mapping between X.400(1988) / ISO
  270.          10021 and RFC-822.
  271.  
  272.     [RFC-1328]
  273.          S.E. Hardcastle-Kille, X.400 1988 to 1984 downgrading.
  274.  
  275.     [MAPPING]
  276.          H.T. Alvestrand, R.S. Miles, M.T. Rose, S.J. Thompson,
  277.          Mapping between X.400 and RFC-822 Message Bodies Internet-
  278.          Draft, (June, 1992).
  279.  
  280.  
  281.  
  282.  
  283.  
  284. Alvestrand et al         Expires Aug 23 1993                  [Page 5]
  285.  
  286. draft                          HARPOON                          Jan 93
  287.  
  288.  
  289.     Table of Contents
  290.  
  291.  
  292.      Status of this Memo ........................................    1
  293.     1 Introduction ..............................................    3
  294.     2 Basic approach ............................................    3
  295.     3 IA5 fallback format .......................................    4
  296.     4 Implications ..............................................    4
  297.     5 Security considerations ...................................    5
  298.     6 Authors' address ..........................................    5
  299.     7 References ................................................    5
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341. Alvestrand et al         Expires Aug 23 1993                  [Page 6]
  342.  
  343.  
  344.